Multicasting within a wireless communications system

ABSTRACT

An access network determines to transmit multicast messages on a downlink shared channel. The access network receives a multicast registration message and a traffic channel request from at least one access terminal. The access network assigns a traffic channel to the at least one access terminal, and transmits the multicast messages on the downlink shared channel. In another example, the access network can determine a channel type upon which the support a multicast session, can indicate the channel type selection to the at least one access terminal in an announce message and can then transmit the multicast messages for the multicast session on the selected channel type. The at least one access terminal receives the announce message, requests a traffic channel and receives a traffic channel assignment, registers to the multicast session and monitors the downlink shared channel for multicast messages.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a Divisional of U.S. patent application Ser. No.12/489,767, filed Jun. 23, 2009, entitled “MULTICASTING WITHIN AWIRELESS COMMUNICATIONS SYSTEM”, which is by the inventors of thesubject application, is assigned to the assignee hereof and isincorporated herein by reference in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

Embodiments of the present invention are directed to multicasting withina wireless communications system and more particularly to multicastingto a plurality of access terminals over a dynamically selected downlinkchannel within the wireless communications system.

2. Description of the Related Art

Wireless communication systems have developed through variousgenerations, including a first-generation analog wireless phone service(1G), a second-generation (2G) digital wireless phone service (includinginterim 2.5G and 2.75G networks) and a third-generation (3G) high speeddata/Internet-capable wireless service. There are presently manydifferent types of wireless communication systems in use, includingCellular and Personal Communications Service (PCS) systems. Examples ofknown cellular systems include the cellular Analog Advanced Mobile PhoneSystem (AMPS), and digital cellular systems based on Code DivisionMultiple Access (CDMA), Frequency Division Multiple Access (FDMA), TimeDivision Multiple Access (TDMA), the Global System for Mobile access(GSM) variation of TDMA, and newer hybrid digital communication systemsusing both TDMA and CDMA technologies.

The method for providing CDMA mobile communications was standardized inthe United States by the Telecommunications IndustryAssociation/Electronic Industries Association in TIA/EIA/IS-95-Aentitled “Mobile Station-Base Station Compatibility Standard forDual-Mode Wideband Spread Spectrum Cellular System,” referred to hereinas IS-95. Combined AMPS & CDMA systems are described in TIA/EIA StandardIS-98. Other communications systems are described in the IMT-2000/UM, orInternational Mobile Telecommunications System 2000/Universal MobileTelecommunications System, standards covering what are referred to aswideband CDMA (WCDMA), CDMA2000 (such as CDMA2000 1xEV-DO standards, forexample) or TD-SCDMA.

In wireless communication systems, mobile stations, handsets, or accessterminals (AT) receive signals from fixed position base stations (alsoreferred to as cell sites or cells) that support communication links orservice within particular geographic regions adjacent to or surroundingthe base stations. Base stations provide entry points to an accessnetwork (AN)/radio access network (RAN), which is generally a packetdata network using standard Internet Engineering Task Force (IETF) basedprotocols that support methods for differentiating traffic based onQuality of Service (QoS) requirements. Therefore, the base stationsgenerally interact with ATs through an over the air interface and withthe AN through Internet Protocol (IP) network data packets.

In wireless telecommunication systems, Push-to-talk (PTT) capabilitiesare becoming popular with service sectors and consumers. PTT can supporta “dispatch” voice service that operates over standard commercialwireless infrastructures, such as CDMA, FDMA, TDMA, GSM, etc. In adispatch model, communication between endpoints (ATs) occurs withinvirtual groups, wherein the voice of one “talker” is transmitted to oneor more “listeners.” A single instance of this type of communication iscommonly referred to as a dispatch call, or simply a PTT call. A PTTcall is an instantiation of a group, which defines the characteristicsof a call. A group in essence is defined by a member list and associatedinformation, such as group name or group identification.

Conventionally, data packets within a wireless communications networkhave been configured to be sent to a single destination or accessterminal A transmission of data to a single destination is referred toas “unicast”. As mobile communications have increased, the ability totransmit given data concurrently to multiple access terminals has becomemore important. Accordingly, protocols have been adopted to supportconcurrent data transmissions of the same packet or message to multipledestinations or target access terminals. A “broadcast” refers to atransmission of data packets to all destinations or access terminals(e.g., within a given cell, served by a given service provider, etc.),while a “multicast” refers to a transmission of data packets to a givengroup of destinations or access terminals. In an example, the givengroup of destinations or “multicast group” may include more than one andless than all of possible destinations or access terminals (e.g., withina given group, served by a given service provider, etc.). However, it isat least possible in certain situations that the multicast groupcomprises only one access terminal, similar to a unicast, oralternatively that the multicast group comprises all access terminals(e.g., within a cell or sector), similar to a broadcast.

Broadcasts and/or multicasts may be performed within wirelesscommunication systems in a number of ways, such as performing aplurality of sequential unicast operations to accommodate the multicastgroup, allocating a unique broadcast/multicast channel (BCH) forhandling multiple data transmissions at the same time and the like. Aconventional system using a broadcast channel for push-to-talkcommunications is described in United States Patent ApplicationPublication No. 2007/0049314 dated Mar. 1, 2007 and entitled“Push-To-Talk Group Call System Using CDMA 1x-EVDO Cellular Network”,the contents of which are incorporated herein by reference in itsentirety. As described in Publication No. 2007/0049314, a broadcastchannel can be used for push-to-talk calls using conventional signalingtechniques. Although the use of a broadcast channel may improvebandwidth requirements over conventional unicast techniques, theconventional signaling of the broadcast channel can still result inadditional overhead and/or delay and may degrade system performance.

The 3^(rd) Generation Partnership Project 2 (“3GPP2”) defines abroadcast-multicast service (BCMCS) specification for supportingmulticast communications in CDMA2000 networks. Accordingly, a version of3GPP2's BCMCS specification, entitled “CDMA2000 High RateBroadcast-Multicast Packet Data Air Interface Specification”, dated Feb.14, 2006, Version 1.0 C.S0054-A, is hereby incorporated by reference inits entirety.

SUMMARY

An access network determines to transmit multicast messages on adownlink shared channel. The access network receives a multicastregistration message and a traffic channel request from at least oneaccess terminal. The access network assigns a traffic channel to the atleast one access terminal, and transmits the multicast messages on thedownlink shared channel. In another example, the access network candetermine a channel type upon which the support a multicast session, canindicate the channel type selection to the at least one access terminalin an announce message and can then transmit the multicast messages forthe multicast session on the selected channel type. The at least oneaccess terminal receives the announce message, requests a trafficchannel and receives a traffic channel assignment, registers to themulticast session and monitors the downlink shared channel for multicastmessages.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of embodiments of the invention and many ofthe attendant advantages thereof will be readily obtained as the samebecomes better understood by reference to the following detaileddescription when considered in connection with the accompanying drawingswhich are presented solely for illustration and not limitation of theinvention, and in which:

FIG. 1 is a diagram of a wireless network architecture that supportsaccess terminals and access networks in accordance with at least oneembodiment of the invention.

FIG. 2 illustrates the carrier network according to an exampleembodiment of the present invention.

FIG. 3 is an illustration of an access terminal in accordance with atleast one embodiment of the invention.

FIG. 4A illustrates a multicast call-setup process for a multicastsession to be carried on a downlink broadcast channel (BCH) in bothtarget and supporting sectors according to an embodiment of the presentinvention.

FIG. 4B illustrates a cluster formed during the process of FIG. 4A.

FIG. 5A illustrates a multicast call-setup process for a multicastsession to be carried on a downlink control channel (CCH) in targetsectors according to an embodiment of the present invention.

FIG. 5B illustrates a cluster formed during the process of FIG. 5A.

FIG. 5C illustrates an example of a control channel cycle of thedownlink CCH.

FIG. 6A illustrates a process for updating a cluster formed inaccordance with FIG. 4A according to an embodiment of the presentinvention.

FIGS. 6B and 6C illustrates clusters at different stages of the updateprocess of FIG. 6A.

FIG. 7A illustrates a process for updating a cluster formed inaccordance with FIG. 5A according to an embodiment of the presentinvention.

FIGS. 7B and 7C illustrate clusters at different stages of the updateprocess of FIG. 7.

DETAILED DESCRIPTION

Aspects of the invention are disclosed in the following description andrelated drawings directed to specific embodiments of the invention.Alternate embodiments may be devised without departing from the scope ofthe invention. Additionally, well-known elements of the invention willnot be described in detail or will be omitted so as not to obscure therelevant details of the invention.

The words “exemplary” and/or “example” are used herein to mean “servingas an example, instance, or illustration.” Any embodiment describedherein as “exemplary” and/or “example” is not necessarily to beconstrued as preferred or advantageous over other embodiments. Likewise,the term “embodiments of the invention” does not require that allembodiments of the invention include the discussed feature, advantage ormode of operation.

Further, many embodiments are described in terms of sequences of actionsto be performed by, for example, elements of a computing device. It willbe recognized that various actions described herein can be performed byspecific circuits (e.g., application specific integrated circuits(ASICs)), by program instructions being executed by one or moreprocessors, or by a combination of both. Additionally, these sequence ofactions described herein can be considered to be embodied entirelywithin any form of computer readable storage medium having storedtherein a corresponding set of computer instructions that upon executionwould cause an associated processor to perform the functionalitydescribed herein. Thus, the various aspects of the invention may beembodied in a number of different forms, all of which have beencontemplated to be within the scope of the claimed subject matter. Inaddition, for each of the embodiments described herein, thecorresponding form of any such embodiments may be described herein as,for example, “logic configured to” perform the described action.

A High Data Rate (HDR) subscriber station, referred to herein as anaccess terminal (AT), may be mobile or stationary, and may communicatewith one or more HDR base stations, referred to herein as modem pooltransceivers (MPTs) or base stations (BS). An access terminal transmitsand receives data packets through one or more modem pool transceivers toan HDR base station controller, referred to as a modem pool controller(MPC), base station controller (BSC) and/or packet control function(PCF). Modem pool transceivers and modem pool controllers are parts of anetwork called an access network. An access network transports datapackets between multiple access terminals.

The access network may be further connected to additional networksoutside the access network, such as a corporate intranet or theInternet, and may transport data packets between each access terminaland such outside networks. An access terminal that has established anactive traffic channel connection with one or more modem pooltransceivers is called an active access terminal, and is said to be in atraffic state. An access terminal that is in the process of establishingan active traffic channel connection with one or more modem pooltransceivers is said to be in a connection setup state. An accessterminal may be any data device that communicates through a wirelesschannel or through a wired channel, for example using fiber optic orcoaxial cables. An access terminal may further be any of a number oftypes of devices including but not limited to PC card, compact flash,external or internal modem, or wireless or wireline phone. Thecommunication link through which the access terminal sends signals tothe modem pool transceiver is called a reverse link or traffic channel.The communication link through which a modem pool transceiver sendssignals to an access terminal is called a forward link or trafficchannel. As used herein the term traffic channel can refer to either aforward or reverse traffic channel.

FIG. 1 illustrates a block diagram of one exemplary embodiment of awireless system 100 in accordance with at least one embodiment of theinvention. System 100 can contain access terminals, such as cellulartelephone 102, in communication across an air interface 104 with anaccess network or radio access network (RAN) 120 that can connect theaccess terminal 102 to network equipment providing data connectivitybetween a packet switched data network (e.g., an intranet, the Internet,and/or carrier network 126) and the access terminals 102, 108, 110, 112.As shown here, the access terminal can be a cellular telephone 102, apersonal digital assistant 108, a pager 110, which is shown here as atwo-way text pager, or even a separate computer platform 112 that has awireless communication portal. Embodiments of the invention can thus berealized on any form of access terminal including a wirelesscommunication portal or having wireless communication capabilities,including without limitation, wireless modems, PCMCIA cards, personalcomputers, telephones, or any combination or sub-combination thereof.Further, as used herein, the terms “access terminal”, “wireless device”,“client device”, “mobile terminal” and variations thereof may be usedinterchangeably.

Referring back to FIG. 1, the components of the wireless network 100 andinterrelation of the elements of the exemplary embodiments of theinvention are not limited to the configuration illustrated. System 100is merely exemplary and can include any system that allows remote accessterminals, such as wireless client computing devices 102, 108, 110, 112to communicate over-the-air between and among each other and/or betweenand among components connected via the air interface 104 and RAN 120,including, without limitation, carrier network 126, the Internet, and/orother remote servers.

The RAN 120 controls messages (typically sent as data packets) sent to abase station controller/packet control function (BSC/PCF) 122. TheBSC/PCF 122 is responsible for signaling, establishing, and tearing downbearer channels (i.e., data channels) between a packet data service node160 (“PDSN”) and the access terminals 102/108/110/112. If link layerencryption is enabled, the BSC/PCF 122 also encrypts the content beforeforwarding it over the air interface 104. The function of the BSC/PCF122 is well-known in the art and will not be discussed further for thesake of brevity. The carrier network 126 may communicate with theBSC/PCF 122 by a network, the Internet and/or a public switchedtelephone network (PSTN). Alternatively, the BSC/PCF 122 may connectdirectly to the Internet or external network. Typically, the network orInternet connection between the carrier network 126 and the BSC/PCF 122transfers data, and the PSTN transfers voice information. The BSC/PCF122 can be connected to multiple base stations (BS) or modem pooltransceivers (MPT) 124. In a similar manner to the carrier network, theBSC/PCF 122 is typically connected to the MPT/BS 124 by a network, theInternet and/or PSTN for data transfer and/or voice information. TheMPT/BS 124 can broadcast data messages wirelessly to the accessterminals, such as cellular telephone 102. The MPT/BS 124, BSC/PCF 122and other components may form the RAN 120, as is known in the art.However, alternate configurations may also be used and the invention isnot limited to the configuration illustrated. For example, in anotherembodiment the functionality of the BSC/PCF 122 and one or more of theMPT/BS 124 may be collapsed into a single “hybrid” module having thefunctionality of both the BSC/PCF 122 and the MPT/BS 124.

FIG. 2 illustrates the carrier network 126 according to an embodiment ofthe present invention. In the embodiment of FIG. 2, the carrier network126 includes a packet data serving node (PDSN) 160, a broadcast servingnode (BSN) 165, an application server 170 and an Internet 175. However,application server 170 and other components may be located outside thecarrier network in alternative embodiments. The PDSN 160 provides accessto the Internet 175, intranets and/or remote servers (e.g., applicationserver 170) for mobile stations (e.g., access terminals, such as 102,108, 110, 112 from FIG. 1) utilizing, for example, a cdma2000 RadioAccess Network (RAN) (e.g., RAN 120 of FIG. 1). Acting as an accessgateway, the PDSN 160 may provide simple IP and mobile IP access,foreign agent support, and packet transport. The PDSN 160 can act as aclient for Authentication, Authorization, and Accounting (AAA) serversand other supporting infrastructure and provides mobile stations with agateway to the IP network as is known in the art. As shown in FIG. 2,the PDSN 160 may communicate with the RAN 120 (e.g., the BSC/PCF 122)via a conventional A10 connection. The A10 connection is well-known inthe art and will not be described further for the sake of brevity.

Referring to FIG. 2, the broadcast serving node (BSN) 165 may beconfigured to support multicast and broadcast services. The BSN 165 willbe described in greater detail below. The BSN 165 communicates with theRAN 120 (e.g., the BSC/PCF 122) via a broadcast (BC) A10 connection, andwith the application server 170 via the Internet 175. The BCA10connection is used to transfer multicast and/or broadcast messaging.Accordingly, the application server 170 sends unicast messaging to thePDSN 160 via the Internet 175, and sends multicast messaging to the BSN165 via the Internet 175.

Generally, as will be described in greater detail below, the RAN 120transmits multicast messages, received from the BSN 165 via the BCA10connection, over a broadcast channel (BCH) of the air interface 104 toone or more access terminals 200.

Referring to FIG. 3, an access terminal 200, (here a wireless device),such as a cellular telephone, has a platform 202 that can receive andexecute software applications, data and/or commands transmitted from theRAN 120 that may ultimately come from the carrier network 126, theInternet and/or other remote servers and networks. The platform 202 caninclude a transceiver 206 operably coupled to an application specificintegrated circuit (“ASIC” 208), or other processor, microprocessor,logic circuit, or other data processing device. The ASIC 208 or otherprocessor executes the application programming interface (“API’) 210layer that interfaces with any resident programs in the memory 212 ofthe wireless device. The memory 212 can be comprised of read-only orrandom-access memory (RAM and ROM), EEPROM, flash cards, or any memorycommon to computer platforms. The platform 202 also can include a localdatabase 214 that can hold applications not actively used in memory 212.The local database 214 is typically a flash memory cell, but can be anysecondary storage device as known in the art, such as magnetic media,EEPROM, optical media, tape, soft or hard disk, or the like. Theinternal platform 202 components can also be operably coupled toexternal devices such as antenna 222, display 224, push-to-talk button228 and keypad 226 among other components, as is known in the art.

Accordingly, an embodiment of the invention can include an accessterminal including the ability to perform the functions describedherein. As will be appreciated by those skilled in the art, the variouslogic elements can be embodied in discrete elements, software modulesexecuted on a processor or any combination of software and hardware toachieve the functionality disclosed herein. For example, ASIC 208,memory 212, API 210 and local database 214 may all be used cooperativelyto load, store and execute the various functions disclosed herein andthus the logic to perform these functions may be distributed overvarious elements. Alternatively, the functionality could be incorporatedinto one discrete component. Therefore, the features of the accessterminal in FIG. 3 are to be considered merely illustrative and theinvention is not limited to the illustrated features or arrangement.

The wireless communication between the access terminal 102 and the RAN120 can be based on different technologies, such as code divisionmultiple access (CDMA), WCDMA, time division multiple access (TDMA),frequency division multiple access (FDMA), Orthogonal Frequency DivisionMultiplexing (OFDM), the Global System for Mobile Communications (GSM),or other protocols that may be used in a wireless communications networkor a data communications network. The data communication is typicallybetween the client device 102, MPT/BS 124, and BSC/PCF 122. The BSC/PCF122 can be connected to multiple data networks such as the carriernetwork 126, PSTN, the Internet, a virtual private network, and thelike, thus allowing the access terminal 102 access to a broadercommunication network. As discussed in the foregoing and known in theart, voice transmission and/or data can be transmitted to the accessterminals from the RAN using a variety of networks and configurations.Accordingly, the illustrations provided herein are not intended to limitthe embodiments of the invention and are merely to aid in thedescription of aspects of embodiments of the invention.

Below, a description of multicast call-setup for multicast sessions thatare carried on a downlink broadcast channel (BCH) in both target andsupporting sectors will be described, followed by a description ofmulticast call-setup for multicast sessions that are carried on adownlink control channel (CCH) in one or more target sectors (e.g., butnot necessarily in supporting sectors). As used herein, a target sectoris any sector within a wireless communications system, having (orexpected to have) at least one multicast group member, that carries amulticast flow for a given multicast session, and a supporting sector isany sector within the wireless communications system, that is notexpected to have multicast group members, and also carries the multicastflow (e.g., to enable soft combining in target sectors for high-datarate multicast communications). Target and supporting sector behavior isdiscussed in more detail within co-pending U.S. patent application Ser.No. 12/212,505, entitled “MULTICAST COMMUNICATIONS WITHIN A WIRELESSCOMMUNICATIONS NETWORK”, filed on Sep. 17, 2008, assigned to theassignee hereof, and expressly incorporated by reference herein in itsentirety.

Accordingly, FIG. 4A illustrates a multicast call-setup process for amulticast session to be carried on a downlink BCH in both target andsupporting sectors according to an embodiment of the present invention.Referring to FIG. 4A, in 400, the application server 170 (e.g., a Qchator Push-to-Talk (PTT) server) receives a request to initiate a multicastsession (e.g., from a PTT initiator, not shown). In 405, the applicationserver 170 forwards an announce message to the RAN 120 for transmissionto access terminals (“multicast group members”, e.g., ATs 1 . . . N)that belong to a multicast group of the multicast session. For example,the application server 170 can forward the announce message to the RAN120 through the BSN 165 via a BCA10 connection. In 410, the RAN 120receives the announce message over the BCA10 connection and transmitsthe announce message to ATs 1 . . . N over the air interface 104 (e.g.,as a data-over-signaling (DOS) message addressed to the multicast groupon the downlink CCH, via a standard paging of ATs 1 . . . N, etc.). ATs1 . . . N receive the announce message and one or more of ATs 1 . . . Nregister for the multicast session, 415 (e.g., by transmitting aBCMCSFlowRegistration message) and send an announce acknowledgment (ACK)that the RAN 120 forwards to the application server 170.

Based at least in part on the registrations received from ATs 1 . . . N,the RAN 120 determines the initial target and supporting sectors for themulticast session, 420. FIG. 4B illustrates an example cluster (i.e., aset of target and supporting sectors) that may be formed in 420 of FIG.4A. As shown, FIG. 4B assumes that ATs A . . . G have registered for themulticast session, that ATs A . . . G reside in target sectors T1through T4, respectively, and that target sectors T1 through T4 aresupported by supporting sectors S1 through S12. Cluster origination isdescribed in greater detail within the above-incorporated co-pendingpatent entitled “MULTICAST COMMUNICATIONS WITHIN A WIRELESSCOMMUNICATIONS NETWORK”.

The RAN 120 transmits a scheduling message (e.g., a broadcast overheadmessage (BOM)) in the target and supporting sectors, 425. For example,the BOM can include an advertisement of the announced multicast session,along with information instructing ATs 1 . . . N on how to tune to themulticast session on the downlink BCH (e.g., an interlace-multiplex (IM)pair on the downlink BCH upon which multicast messages for the multicastsession are to be transmitted). In a further example, BOMs transmittedin target sectors are configured to suppress subsequent AT registrations(e.g., to reduce traffic, except for when the RAN 120 wants to confirmthe status of the target sectors), and BOMS transmitted in supportingsectors are configured to prompt AT registrations (e.g., so that the RAN120 can transition the supporting sector to a target sector, asdiscussed below in greater detail). Accordingly, the ATs 1 . . . N thathave received the BOM tune to the indicated IM pair and monitor for themulticast messages, 430.

In 435, after the application server 170 receives a first announce ACKfor the multicast session, the application server 170 begins forwardingmulticast messages (e.g., multicast media messages, such as video,audio, text, etc.) to the RAN 120 via the BSN 165 over the BCA10connection for transmission to ATs 1 . . . N. In 440, the RAN 120receives the multicast messages over the BCA10 connection and transmitsthe multicast messages to ATs 1 . . . N over the air interface 104 onthe BOM-indicated IM pair of the downlink BCH, in both the target andsupporting sectors. The ATs 1 . . . N that have tuned to theBOM-indicated IM pair of the downlink BCH receive and decode themulticast messages, 445.

As will be appreciated by one of ordinary skill in the art, transmittingmulticast messages in supporting sectors to be used for soft combiningfor access terminals within the target sectors helps the accessterminals decode high-data rate broadcasts or multicasts. However, ifthe multicast has a relatively low-data rate, the access terminals maynot necessarily need to soft combine with the supporting sectortransmission to decode the multicast successfully. Also, if multicastgroup members are not geographically densely located (e.g., there arenot a high number of multicast group members in any particular targetsector), then the potentially large number of supporting sectors maydecrease an overall spectral efficiency because many sectors aretransmitting redundant information to reach only a few local multicastgroup members. Also, as mentioned above, after the RAN 120 receives aforwarded multicast message for transmission, the RAN 120 waits for theBOM-indicated IM pair on the downlink BCH for the transmission. Thus,delay or lag is introduced for the duration the RAN 120 waits before thetransmission on a next IM pair.

Accordingly, embodiments of the present invention wherein supportingsectors need not be used and a multicast session is carried on adownlink control channel (CCH) instead of the downlink BCH will now bedescribed in greater detail with respect to FIGS. 5A-5B. Whileembodiments of the invention are described below with respect tocarrying the multicast session on the downlink CCH, it will beappreciated that, in other embodiments of the invention, the multicastsession can be carried on any downlink shared channel, and notnecessarily on the downlink CCH.

Accordingly, FIG. 5A illustrates a multicast call-setup process for amulticast session to be carried on a downlink CCH in one or more targetsectors according to an embodiment of the present invention. Referringto FIG. 5A, in 500, the application server 170 (e.g., a Qchat orPush-to-Talk (PTT) server) receives a request to initiate a multicastsession (e.g., from a PTT initiator, not shown). In 505, the applicationserver 170 forwards the announce message to the RAN 120 for transmissionto ATs 1 . . . N that belong to a multicast group of the multicastsession. For example, the application server 170 can forward theannounce message to the RAN 120 through the BSN 165 via a BCA10connection.

In 510, the RAN 120 receives the announce message over the BCA10connection and determines a channel type (e.g., BCH, CCH, etc.) uponwhich to support the multicast session associated with the announcemessage. For example, the RAN 120 can determine between the downlink CCHand BCH based at least in part upon estimated locations of the multicastgroup members for the announced multicast session. The locations of themulticast group members can be tracked during operation of the wirelesscommunications system 100, and the RAN 120 can maintain a location tablethat indicates the last known position of the multicast group membersbased on route update reports received from the multicast group members.Location tracking of access terminals is discussed in more detail withinco-pending U.S. patent application Ser. No. 12/212,929, entitled“TRACKING LOCATIONS OF MULTICAST GROUP MEMBERS WITHIN A WIRELESSCOMMUNICATION SYSTEM”, having attorney docket no. 072044P1, filed onSep. 18, 2008, assigned to the assignee hereof, and expresslyincorporated by reference herein in its entirety.

Accordingly, in this example, the information contained within thelocation table can be used to decide between multicasting on thedownlink BCH or CCH. In an example, if the number of expected multicastgroup members within a given sector or other geographic partition isabove a threshold, then the BCH-based multicasting discussed withrespect to FIG. 4A-4B can be implemented (e.g., to reduce a likelihoodof overloading the CCH), in an example, and the process may advance to410 of FIG. 4A. In another example, if the number of expected multicastgroup members within the given sector or other geographic partition isnot above a threshold, then the process may advance to 515 and the CCHmay be used.

As will be appreciated, the CCH has a lower data rate (e.g., 76.8 kbps)then the BCH (e.g., 307.2 kbps). Thus, in another example, thedetermination of 510 can be based at least in part upon a data rateassociated with the multicast session. For example, if the expected datarate of the multicast session is above a data rate threshold, then theRAN 120 may select or determine to carry the multicast session on theBCH. Otherwise, if the expected data rate of the multicast session isnot above a data rate threshold, then the RAN 120 may select ordetermine to carry the multicast session on the CCH. In another example,if channel conditions in one or more target sectors are poor, the CCHmay be selected to increase the decoding success rate of the multicastmessages. In another example, if the loading on the CCH is above athreshold in one or more target sectors, the RAN 120 may select the BCHto avoid overloading the CCH.

In another example, any combination of data rate, loading and/orAT-position criteria may be used to determine the channel type for themulticast transmission. Thus, in an example, if the number of multicastgroup members within a sector is high but the data rate for themulticast session is relatively low and the loading on the CCH isrelatively low, the RAN 120 may apply a weighting function to the datarate, loading and sector co-location factors to make the determinationof 510.

In yet another example, the determination of 510 can be RNC or subnetspecific, such that different subnets can carry the multicast session ondifferent channel types. For example, if conditions in a first subnetare better for the CCH and conditions in a second subnet are better forthe BCH, the RNCs in charge of the different subnets need notsynchronize the channel types, and can rather independently determinethe best channel type to use on a per-subnet basis.

In another example, the determination of 510 can be specific to givengroups of sectors within a particular subnet. For example, a first groupor set of sectors within a subnet can be configured to carry a multicastsession on the downlink CCH, while another group of sectors within thesame subnet can be configured to support the multicast session on thedownlink BCH.

Next, assume that the RAN 120 determines to transmit the multicastsession on the CCH, and the process advances to 515. In 515, the RAN 120configures the announce message to be transmitted to ATs 1 . . . N toindicate that the announced multicast session will be carried on theCCH. For example, the RAN can attach a StorageBlobAssignment message tothe announce message that includes a flag indicating the CCH formulticast transmission (e.g., in QChat, the StorageBlobAssignmentmessage can contain an access control message (ACM) with a ‘transmissionmode’ field set to indicate CCH or BCH, in an example). After theannounce message is configured to indicate the CCH, the configuredannounce message is transmitted over the air interface 104, 520 (e.g.,as a mobile-termination data over signaling (MT-DOS) message, or via astandard paging process). In an example, the transmission of theannounce message can be based at least in part on a location tablemaintained at the RAN 120 for tracking multicast group member locations(e.g., MT-DOS announce in proximity to the ATs' expected locations, andstandard paging announce in other sectors). In other words, an initialor estimated target sector set can be established to more efficientlyannounce the multicast session.

ATs 1 . . . N receive the configured announce message, 525, andinterpret the announce message as indicating a multicast transmission onthe downlink CCH. In 530, each of ATs 1 . . . N that are interested inparticipating in the announced multicast session requests a trafficchannel (TCH), 530, from the RAN 120 (e.g., by sending aConnectionRequest message). The RAN 120 assigns the requested TCHs toeach requesting AT, 535. As will be described in greater detail below,the TCH assigned to ATs 1 . . . N allows the RAN 120 to track theprecise locations of ATs 1 . . . N (e.g., during handoffs betweensectors) based on messaging from ATs 1 . . . N that is transmitted on areverse link portion of the assigned TCH. Generally, because ATs 1 . . .N are not necessarily floor-holders of the multicast session, theassigned reverse TCH is not used by ATs 1 . . . N to send media fortransmission to other multicast group members. However, ATs 1 . . . Nmay transmit keep-alive packets so the RAN 120 does not de-allocate theTCHs, and also RouteUpdate messages for location tracking and/or torequest handoff. On the other hand, because the TCH may be assigned forpurposes of location tracking and/or handoff, it will be appreciatedthat the downlink portion of the TCH (F-TCH) may be substantiallysilent, unless the AT is engaged in a separate unicast session using theassigned TCH. Thus, the F-TCH does not necessarily consume forward linkresources (i.e., timeslots), while the R-TCH permits location trackingof the AT by the RAN 120.

Next, in 540, after the TCH(s) are assigned in 535, one or more of ATs 1. . . N register for the multicast session, 415 (e.g., by transmitting aBCMCSFlowRegistration message) and also send an announce acknowledgment(ACK) that the RAN 120 forwards to the application server 170. It willbe appreciated that once one or more of ATs 1 . . . N attempt toregister to the announced multicast session, the RAN 120 becomes awarethat one or more listeners are in the sector and can begin forwardingmulticast traffic on the downlink CCH, as described below with respectto 560 and 565. Also, in an example, the scheduling message or BOM neednot be transmitted because each AT monitors the CCH continuously, andeach AT need not be informed of a designated IM pair on the BCH becausethe multicast session is being carried on the CCH. In an example, whileshown separately in FIG. 5A, the TCH request of 530 can be bundled withthe announce ACK and multicast registration requests of 540 in at leastone embodiment.

Based at least in part on the registrations received from ATs 1 . . . N,the RAN 120 determines the target sectors for the multicast session,550. In an example, step 550 may generate an initial set of targetsectors for the multicast session. In another example, step 550 mayupdate an already existing set of target sectors that are determinedprior to transmission of the announce message in 520 (e.g., based on alocation table for tracking the multicast group members, as discussedabove). As will be appreciated, the RAN 120 need not determinesupporting sectors for the multicast session because the low data-rateof the CCH is easier for ATs to decode, and as such the overheadassociated with the supporting sectors can be reduced or omitted becausesoft combining may not be necessary. FIG. 5B illustrates an examplecluster (i.e., with only target sectors) that may be formed in 550 ofFIG. 5A. As shown, FIG. 5B assumes that ATs A . . . G have registeredfor the multicast session, and that ATs A . . . G reside in targetsectors T1 through T4. In contrast to FIG. 4B, in the example of FIG.5B, the supporting sectors S1 through S12 need not be included in thecluster.

In 555, after the application server 170 receives a first announce ACKfor the multicast session, the application server 170 begins forwardingmulticast messages (e.g., multicast media messages, such as video,audio, text, etc.) to the RAN 120 via the BSN 165 over the BCA10connection for transmission to one or more of ATs 1 . . . N. In 560, theRAN 120 receives the multicast messages over the BCA10 connection andschedules the multicast messages on the CCH. For example, the multicastmessages can be scheduled on an asynchronous control channel capsule ofa given control channel cycle of the CCH, as will now be described ingreater detail with respect to FIG. 5C.

FIG. 5C illustrates an example of a control channel cycle of thedownlink CCH. Referring to FIG. 5C, each control channel cycle includesa total of 256 slots. Each control channel cycle includes a synchronouscontrol channel capsule (SC), a plurality of asynchronous controlchannel capsules (ACs), and a plurality of sub-synchronous controlchannels (SSCs). One SC is regularly or periodically transmitted at agiven timeslot for each control channel cycle having a period of 256slots, whereas the ACs are transmitted at “random”, or atnon-synchronous timeslots, within the control channel cycle. The SC isfirst transmitted at a timeslot corresponding to “T mod 256=Offset”, andthen retransmitted at a timeslot corresponding to “T mod 4=Offset”,where T denotes a system time and an Offset denotes a time value delayedfrom a fixed time, which are included in the control channel header.Each SC may include a plurality of control channel MAC layer packets,whereas each AC includes only one control channel MAC layer packet, inan example. As each MPT/BS 124 periodically transmits one or morecontrol channel MAC layer packets, interference (e.g., inter-cellinterference) may occur if each MPT/BS 124 transmits at the same time.Accordingly, a different offset is applied to the SC for each MPT/BS 124to avoid collisions. The MPT/BS may transmit as many as three SSCcapsules within one control channel period or 256 slot cycle. Each SSCtypically transmits only one control channel MAC layer packet. Assumingan offset value of 2, the SSCs are transmitted at time slots 66, 130 and194. Unlike SCs and SSCs, ACs can start anytime within a control channelcycle. Therefore, messages sent on ACs do not need to wait forpre-defined time slots. Control channel capsules (e.g., SCs, ACs, SSCs,etc.) are generally well-known in the art within BCMCS systems, and assuch a further description thereof has been omitted for the sake ofbrevity.

In an example, using the asynchronous control channel capsule can resultin a reduction of the delay associated with BCH transmissions, whichwait for the BOM-indicated IM pair, because the asynchronous controlchannel capsules occur more frequently (e.g., on each non synchronous orsub-synchronous control channel capsule). Next, in 565, the RAN 120transmits the multicast messages to ATs 1 . . . N over the air interface104 on the CCH as scheduled in 560, in each target sector. The ATs 1 . .. N monitor the CCH and received the multicast transmissions, 570.

As will be appreciated by one of ordinary skill in the art, the numberof supporting sectors can be reduced and/or eliminated by using the CCHto carry the multicast flow for given multicast session. Below, clusteradjustments (e.g., the addition or removal of target/supporting sectors)are described with respect to both supporting sector and non-supportingsector embodiments of the invention.

Processes for adjusting clusters within a combination target andsupporting sector scenario are described in detail within co-pendingU.S. patent application Ser. No. 12/212,505, entitled “MULTICASTCOMMUNICATIONS WITHIN A WIRELESS COMMUNICATIONS NETWORK”, filed on Sep.17, 2008, which has already been incorporated by reference above in itsentirety. Accordingly, a brief description of cluster adjustments withina combination target and supporting sector scenario will be providedbelow to provide context, followed by a description of a CCH-basedmulticast within a target-sector only embodiment.

In an example, assume that the process of FIG. 4A is executed and thatthe cluster of FIG. 4B is active. With these assumptions, after 445 ofFIG. 4A, the process advances to 600 of FIG. 6A. In 600, AT G moves fromtarget sector T4 to adjacent supporting sector S7, as shown in FIG. 6B.As is characteristic of a supporting sector, the RAN 120 is alreadytransmitting the multicast flow on the downlink BCH in supporting sectorS7, 605. In 610, the RAN 120 transmits a periodic BOM, and AT G tunes tothe BOM-indicated IM pair on the downlink BCH in sector S7, 615. The BOMtransmitted is also configured (e.g., RFDB=‘1’) to prompt AT G torespond with a registration message (e.g., a BCMCSFlowRegistrationmessage), and AT G transmits the registration message, 620. The RAN 120receives the registration message and updates the cluster based on theknowledge that AT G has left sector T4 and entered sector S7, 625. Inparticular, target sector T4 is removed from the set of target sectors(i.e., because no multicast group members are present), supportingsector S7 is transitioned to a target sector T5 and added to the set oftarget sectors, and the set of supporting sectors is updated to accountfor the loss of target sector T4 and addition of target sector T5. FIG.6C illustrates an example of the updated cluster of 625. In 630, the RAN120 transmits the multicast messages for the multicast session on thedownlink BCH within the target and supporting sectors of the updatedcluster.

In an example, assume that the process of FIG. 5A is executed and thatthe cluster of FIG. 5B is active. With these assumptions, after 570 ofFIG. 5A, the process advances to 700 of FIG. 7A. In 700, AT G beginsmoving from target sector T4 to an adjacent non-target sector, as shownin FIG. 7B. Because the adjacent sector is a non-target sector and thisexample cluster does not include supporting sectors, AT G's new clusteris not transmitting multicast messages for the multicast session. In705, the RAN 120 continues to transmit multicast messages within sectorT4. In 710, AT G is handed off from target sector T4 to the new sector,which is triggered by the RouteUpdate message sent by AT G on theassigned R-TCH to the RAN 120. Handoff (e.g., soft handoff, hardhandoff, etc.) is well known in the art. Here, the inter-sector handoffof AT G is possible because AT G was previously assigned a TCH in 535 ofFIG. 5A. Because the RAN 120 has handed off AT G from target sector T4to the new sector, the RAN 120 is aware of AT G's new location, and canupdate a location table that tracks AT locations with AT G's newposition. Further, the RAN 120 updates the cluster by ceasingtransmission of multicast messages in target sector T4 and transitioningtarget sector T4 to a non-target sector (e.g., because no multicastgroup members remain in T4 after AT G leaves), 715, and transitions ATG's new sector to target sector T5. FIG. 7C illustrates an example ofthe updated cluster of 715/720 of FIG. 7A. In 725, the RAN 120 transmitsthe multicast messages for the multicast session on the downlink CCHwithin the target sectors of the updated cluster, which are monitored byAT G, 730.

In another embodiment of the invention, while not described above, itwill be appreciated that the determining step of 510 of FIG. 5A may alsobe performed during an active multicast session, and not merely inadvance of an announce message transmission. Thus, the RAN 120 cantoggle a multicast session back and forth between the BCH and CCH basedon current operating parameters, in an example (e.g., if the number ofmulticast group members rises above or falls below a threshold duringoperation, etc.). Because there is overhead associated with this type ofdynamic switching, the thresholds associated with an active-sessionchannel switch may be different than the thresholds associated with 510of FIG. 5A.

Accordingly, as will be appreciated by one of ordinary skill in the artin view of the embodiments described above, a spectral efficiency of thewireless communications system 100 can be increased by transmitting amulticast flow primarily within target sectors on a low data-rate shareddownlink channel, such as the downlink CCH. This allows fewer (e.g.,zero) supporting sectors to be deployed (e.g., within a particularsubnet, within all subnets carrying the session, within a subnet portionconstituting a given group of sectors within the subnet while anothersubnet portion of the same subnet includes supporting sectors, etc.)that carry the multicast flow even though no target ATs are presentwithin the supporting sectors. As discussed above, the RAN 120 can trackthe locations of ATs based on the assigned TCH, such that ATs do notdrop the multicast session when handing off to sectors that are not yetcarrying the multicast flow.

Above, embodiments are generally directed to supporting a multicastsession in one or more subnets on a downlink control channel instead ofa downlink broadcast channel. In general, the downlink control channeltransmits at a lower-data rate than the downlink broadcast channel, andas such soft-combining is less likely to be necessary as compared to thedownlink broadcast channel. However, in another embodiment, themulticast session can be supported on a downlink shared channel that cancorrespond to either the control channel or the broadcast channel. Inthis embodiment, if the downlink shared channel corresponds to thedownlink broadcast channel, soft-combining via one or more supportingsectors can still be omitted so long as a traffic channel is assigned toeach non-floorholder AT for location tracking during the multicastsession (e.g., so the session is not dropped if an AT hands off to anon-target sector). While an error rate of the downlink BCH embodimentwithout supporting sectors may be higher than an error rate if thesession were supported on the downlink CCH, it will also be appreciatedthat carrying the session on the downlink BCH reduces the load on thedownlink CCH.

Those of skill in the art will appreciate that information and signalsmay be represented using any of a variety of different technologies andtechniques. For example, data, instructions, commands, information,signals, bits, symbols, and chips that may be referenced throughout theabove description may be represented by voltages, currents,electromagnetic waves, magnetic fields or particles, optical fields orparticles, or any combination thereof.

Further, those of skill in the art will appreciate that the variousillustrative logical blocks, modules, circuits, and algorithm stepsdescribed in connection with the embodiments disclosed herein may beimplemented as electronic hardware, computer software, or combinationsof both. To clearly illustrate this interchangeability of hardware andsoftware, various illustrative components, blocks, modules, circuits,and steps have been described above generally in terms of theirfunctionality. Whether such functionality is implemented as hardware orsoftware depends upon the particular application and design constraintsimposed on the overall system. Skilled artisans may implement thedescribed functionality in varying ways for each particular application,but such implementation decisions should not be interpreted as causing adeparture from the scope of the present invention.

The various illustrative logical blocks, modules, and circuits describedin connection with the embodiments disclosed herein may be implementedor performed with a general purpose processor, a digital signalprocessor (DSP), an application specific integrated circuit (ASIC), afield programmable gate array (FPGA) or other programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof designed to perform the functions described herein.A general purpose processor may be a microprocessor, but in thealternative, the processor may be any conventional processor,controller, microcontroller, or state machine. A processor may also beimplemented as a combination of computing devices, e.g., a combinationof a DSP and a microprocessor, a plurality of microprocessors, one ormore microprocessors in conjunction with a DSP core, or any other suchconfiguration.

The methods, sequences and/or algorithms described in connection withthe embodiments disclosed herein may be embodied directly in hardware,in a software module executed by a processor, or in a combination of thetwo. A software module may reside in RAM memory, flash memory, ROMmemory, EPROM memory, EEPROM memory, registers, hard disk, a removabledisk, a CD-ROM, or any other form of storage medium known in the art. Anexemplary storage medium is coupled to the processor such that theprocessor can read information from, and write information to, thestorage medium. In the alternative, the storage medium may be integralto the processor. The processor and the storage medium may reside in anASIC. The ASIC may reside in a user terminal (e.g., access terminal). Inthe alternative, the processor and the storage medium may reside asdiscrete components in a user terminal.

In one or more exemplary embodiments, the functions described may beimplemented in hardware, software, firmware, or any combination thereof.If implemented in software, the functions may be stored on ortransmitted over as one or more instructions or code on acomputer-readable medium. Computer-readable media includes both computerstorage media and communication media including any medium thatfacilitates transfer of a computer program from one place to another. Astorage media may be any available media that can be accessed by acomputer. By way of example, and not limitation, such computer-readablemedia can comprise RAM, ROM, EEPROM, CD-ROM or other optical diskstorage, magnetic disk storage or other magnetic storage devices, or anyother medium that can be used to carry or store desired program code inthe form of instructions or data structures and that can be accessed bya computer. Also, any connection is properly termed a computer-readablemedium. For example, if the software is transmitted from a website,server, or other remote source using a coaxial cable, fiber optic cable,twisted pair, digital subscriber line (DSL), or wireless technologiessuch as infrared, radio, and microwave, then the coaxial cable, fiberoptic cable, twisted pair, DSL, or wireless technologies such asinfrared, radio, and microwave are included in the definition of medium.Disk and disc, as used herein, includes compact disc (CD), laser disc,optical disc, digital versatile disc (DVD), floppy disk and blu-ray discwhere disks usually reproduce data magnetically, while discs reproducedata optically with lasers. Combinations of the above should also beincluded within the scope of computer-readable media.

While the foregoing disclosure shows illustrative embodiments of theinvention, it should be noted that various changes and modificationscould be made herein without departing from the scope of the inventionas defined by the appended claims. The functions, steps and/or actionsof the method claims in accordance with the embodiments of the inventiondescribed herein need not be performed in any particular order.Furthermore, although elements of the invention may be described orclaimed in the singular, the plural is contemplated unless limitation tothe singular is explicitly stated.

1. A method of multicasting within a wireless communications system,comprising: receiving an announce message for announcing a multicastsession to a plurality of multicast group members; determining a channeltype upon which to support the multicast session; configuring theannounce message to indicate the determined channel type; transmittingthe configured announce message to the plurality of multicast groupmembers within at least one of a plurality of sectors; and transmittingmulticast messages associated with the announced multicast session onthe determined channel type only within sectors that are expected toinclude one or more of the plurality of multicast group members.
 2. Themethod of claim 1, wherein determining comprises selecting a downlinkshared channel as the channel type upon which to support the multicastsession.
 3. The method of claim 2, wherein the downlink shared channelis a downlink control channel or a downlink broadcast channel.
 4. Themethod of claim 1, wherein configuring comprises generating asupplemental message for indicating the determined channel type, and thetransmission of the configured announce message corresponds to atransmission of the supplemental message along with the announcemessage.
 5. The method of claim 1, wherein the determining is performedon a per-subnet basis, such that different subnets are capable ofselecting different channel types upon which to support the multicastsession.
 6. The method of claim 5, wherein a first subnet performing thedetermining determines to support the multicast session on a downlinkshared channel and a second subnet determines to support the multicastsession on a downlink broadcast channel.
 7. The method of claim 1,wherein the determining is performed independently for each of aplurality of groups of sectors within a given subnet, wherein a firstinstance of the determining determines to support the multicast sessionon a downlink shared channel for a first group of sectors within thegiven subnet, and wherein a second instance of the determiningdetermines to support the multicast session on a downlink broadcastchannel for a second group of sectors within the given subnet.
 8. Themethod of claim 1, further comprising: receiving a multicast sessionregistration from each of the one or more multicast group members torequest registration to the announced multicast session; and if thedetermining determines to support the multicast session on a downlinkshared channel, receiving a traffic channel request from each of the oneor more multicast group members, and assigning a downlink trafficchannel to each of the one or more multicast group members, wherein themulticast messages are transmitted, on the downlink shared channel, onlyin sectors including the one or more multicast group members from whichthe multicast session registrations are received.
 9. An access networkwithin a wireless communications system, comprising: logic configured toreceive an announce message for announcing a multicast session to aplurality of multicast group members; logic configured to determine achannel type upon which to support the multicast session; logicconfigured to configure the announce message to indicate the determinedchannel type; logic configured to transmit the configured announcemessage to the plurality of multicast group members within at least oneof a plurality of sectors; and logic configured to transmit multicastmessages associated with the announced multicast session on thedetermined channel type only within sectors that are expected to includeone or more of the plurality of multicast group members.
 10. Anon-transitory computer-readable storage medium comprising instructionsencoded thereon, which, when executed by an access network within awireless communications system, cause the access network to performoperations, the instructions comprising: program code to receive anannounce message for announcing a multicast session to a plurality ofmulticast group members; program code to determine a channel type uponwhich to support the multicast session; program code to configure theannounce message to indicate the determined channel type; program codeto transmit the configured announce message to the plurality ofmulticast group members within at least one of a plurality of sectors;and program code to transmit multicast messages associated with theannounced multicast session on the determined channel type only withinsectors that are expected to include one or more of the plurality ofmulticast group members.
 11. The access network of claim 9, wherein thelogic configured to determine comprises logic configured to select adownlink shared channel as the channel type upon which to support themulticast session.
 12. The access network of claim 9, wherein the logicconfigured to determine generates a supplemental message for indicatingthe determined channel type, and the transmission of the configuredannounce message corresponds to a transmission of the supplementalmessage along with the announce message.
 13. The access network of claim9, wherein the logic configured to determine determines the channel typeon a per-subnet basis, such that different subnets are capable ofselecting different channel types upon which to support the multicastsession.
 14. The access network of claim 9, wherein the logic configuredto determine determines the channel type independently for each of aplurality of groups of sectors within a given subnet, wherein the logicconfigured to determine determines to support the multicast session on adownlink shared channel for a first group of sectors within the givensubnet, and wherein the logic configured to determine determines tosupport the multicast session on a downlink broadcast channel for asecond group of sectors within the given subnet.
 15. The access networkof claim 9, further comprising: logic configured to receive a multicastsession registration from each of the one or more multicast groupmembers to request registration to the announced multicast session; andlogic configured to receive, if the logic configured to determinedetermines to support the multicast session on a downlink sharedchannel, a traffic channel request from each of the one or moremulticast group members, and to assign a downlink traffic channel toeach of the one or more multicast group members, wherein the multicastmessages are transmitted, on the downlink shared channel, only insectors including the one or more multicast group members from which themulticast session registrations are received.
 16. The non-transitorycomputer-readable storage medium of claim 10, wherein the program codeto determine comprises program code to select a downlink shared channelas the channel type upon which to support the multicast session.
 17. Thenon-transitory computer-readable storage medium of claim 10, wherein theprogram code to determine generates a supplemental message forindicating the determined channel type, and the transmission of theconfigured announce message corresponds to a transmission of thesupplemental message along with the announce message.
 18. Thenon-transitory computer-readable storage medium of claim 10, wherein theprogram code to determine determines the channel type on a per-subnetbasis, such that different subnets are capable of selecting differentchannel types upon which to support the multicast session.
 19. Thenon-transitory computer-readable storage medium of claim 10, wherein theprogram code to determine determines the channel type independently foreach of a plurality of groups of sectors within a given subnet, whereinthe program code to determine determines to support the multicastsession on a downlink shared channel for a first group of sectors withinthe given subnet, and wherein the program code to determine determinesto support the multicast session on a downlink broadcast channel for asecond group of sectors within the given subnet.
 20. The non-transitorycomputer-readable storage medium of claim 10, further comprising:program code to receive a multicast session registration from each ofthe one or more multicast group members to request registration to theannounced multicast session; and program code to receive, if the programcode to determine determines to support the multicast session on adownlink shared channel, a traffic channel request from each of the oneor more multicast group members, and to assign a downlink trafficchannel to each of the one or more multicast group members, wherein themulticast messages are transmitted, on the downlink shared channel, onlyin sectors including the one or more multicast group members from whichthe multicast session registrations are received.